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1. Abstract 


SMTP was defined as a message *transfer* protocol, that is, a means 
to route (if needed) and deliver finished (complete) messages. 
Message Transfer Agents (MTAs) are not supposed to alter the message 
text, except to add ’Received’, ’Return-Path’, and other header 
fields as required by [SMTP-MTA]. 


However, SMTP is now also widely used as a message *submission* 
protocol, that is, a means for message user agents (MUAS) to 
introduce new messages into the MTA routing network. The process 
which accepts message submissions from MUAS is termed a Message 
Submission Agent (MSA). 


Messages being submitted are in some cases finished (complete) 
messages, and in other cases are unfinished (incomplete) in some 
aspect or other. Unfinished messages need to be completed to ensure 
they conform to [MESSAGE-FORMAT], and later requirements. For 
example, the message may lack a proper ’Date’ header field, and 
domains might not be fully qualified. In some cases, the MUA may be 
unable to generate finished messages (for example, it might not know 
its time zone). Even when submitted messages are complete, local 
site policy may dictate that the message text be examined or modified 
in some way. Such completions or modifications have been shown to 
cause harm when performed by downstream MTAs -- that is, MTAs after 
the first-hop submission MTA -- and are in general considered to be 
outside the province of standardized MTA functionality. 


Separating messages into submissions and transfers allows developers 
and network administrators to more easily: 


* Implement security policies and guard against unauthorized mail 
relaying or injection of unsolicited bulk mail 


i Implement authenticated submission, including off-site submission 
by authorized users such as travelers 
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* Separate the relevant software code differences, thereby making 
each code base more straightforward and allowing for different 
programs for relay and submission 


A Detect configuration problems with a site’s mail clients 
* Provide a basis for adding enhanced submission services in the 
future 


This memo describes a low cost, deterministic means for messages to 
be identified as submissions, and specifies what actions are to be 
taken by a submission server. 


Public comments should be sent to the IETF Submit mailing list, 
<ietf-submit@imc.org>. To subscribe, send a message containing 
SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments may be 
sent to the authors. 
Document Information 

Definitions of Terms Used in this Memo 
Fully-Qualified 
Containing or consisting of a domain which can be globally resolved 
using the global Domain Name Service; that is, not a local alias or 
partial specification. 
Message Submission Agent (MSA) 
A process which conforms to this specification, which acts as a 


submission server to accept messages from MUAS, and either delivers 
them or acts as an SMTP client to relay them to an MTA. 


Message Transfer Agent (MTA) 


A process which conforms to [SMTP-MTA], which acts as an SMTP server 
to accept messages from an MSA or another MTA, and either delivers 
them or acts as an SMTP client to relay them to another MTA. 


Message User Agent (MUA) 
A process which acts (usually on behalf of a user) to compose and 


submit new messages, and process delivered messages. In the split- 
MUA model, POP or IMAP is used to access delivered messages. 
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Conventions Used in this Document 
In examples, "C:" is used to indicate lines sent by the client, and 
"S:" indicates those sent by the server. Line breaks within a 


command example are for editorial purposes only. 
Examples use the ’example.net’ domain. 


The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 
in this document are to be interpreted as defined in [KEYWORDS]. 


Message Submission 
Submission Identification 


Port 587 is reserved for email message submission as specified in 
this document. Messages received on this port are defined to be 

submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with 

additional restrictions as specified here. 


While most email clients and servers can be configured to use port 
587 instead of 25, there are cases where this is not possible or 
convenient. A site MAY choose to use port 25 for message submission, 
by designating some hosts to be MSAs and others to be MTAs. 


Message Rejection and Bouncing 


MTAs and MSAs MAY implement message rejection rules that rely in part 
on whether the message is a submission or a relay. 


For example, some sites might configure their MTA to reject all RCPT 
TOs for messages that do not reference local users, and configure 
their MSA to reject all message submissions that do not come from 
authorized users, based on IP address, or authenticated identity. 


NOTE: It is better to reject a message than to risk sending one that 
is damaged. This is especially true for problems that are 
correctable by the MUA, for example, an invalid ’From’ field. 


If an MSA is not able to determine a return path to the submitting 
user, from a valid MAIL FROM, a valid source IP address, or based on 
authenticated identity, then the MSA SHOULD immediately reject the 
message. A message can be immediately rejected by returning a 550 
code to the MAIL FROM command. 
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Note that a null return path, that is, MAIL FROM:<>, is permitted 
and MUST be accepted. (MUAS need to generate null return-path 
messages for a variety of reasons, including disposition 
notifications.) 


Except in the case where the MSA is unable to determine a valid 
return path for the message being submitted, text in this 
specification which instructs an MSA to issue a rejection code MAY be 
complied with by accepting the message and subsequently generating a 
bounce message. (That is, if the MSA is going to reject a message for 
any reason except being unable to determine a return path, it can 
optionally do an immediate rejection or accept the message and then 
mail a bounce.) 


NOTE: In the normal case of message submission, immediately 
rejecting the message is preferred, as it gives the user and MUA 
direct feedback. To properly handle delayed bounces the client MUA 
must maintain a queue of messages it has submitted, and match bounces 
to them. 


3.3. Authorized Submission 


Numerous methods have been used to ensure that only authorized users 


are able to submit messages. These methods include authenticated 
SMTP, IP address restrictions, secure IP, and prior POP 
authentication. 


Authenticated SMTP [SMTP-AUTH] has been proposed. It allows the MSA 
to determine an authorization identity for the message submission, 
which is not tied to other protocols. 


IP address restrictions are very widely implemented, but do not allow 
for travellers and similar situations, and can be spoofed. 


Secure IP [IPSEC] can also be used, and provides additional benefits 
of protection against eavesdropping and traffic analysis. 


Requiring a POP [POP3] authentication (from the same IP address) 
within some amount of time (for example, 20 minutes) prior to the 
start of a message submission session has also been used, but this 
does impose restrictions on clients as well as servers which may 
cause difficulties. Specifically, the client must do a POP 
authentication before an SMTP submission session, and not all clients 
are capable and configured for this. Also, the MSA must coordinate 
with the POP server, which may be difficult. There is also a window 
during which an unauthorized user can submit messages and appear to 
be a prior authorized user. 
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3.4. Enhanced Status Codes 


This memo suggests several enhanced status codes [SMTP-CODES] for 


submission-specific rejections. The specific codes used are: 
5.6.0 Bad content. The content of the header or text is 
improper. 
5.6.2 Bad domain or address. Invalid or improper domain or address 


in MAIL FROM, RCPT TO, or DATA. 


5.7.1 Not allowed. The address in MAIL FROM appears to have 
insufficient submission rights, or is invalid, or is not 
authorized with the authentication used; the address ina 
RCPT TO command is inconsistent with the permissions given to 
the user; the message data is rejected based on the 
submitting user. 


5.7.0 Site policy. The message appears to violate site policy in 
some way. 


4. Mandatory Actions 
An MSA MUST do all of the following: 

4.1. General Submission Rejection Code 
Unless covered by a more precise response code, response code 554 is 
to be used to reject a MAIL FROM, RCPT TO, or DATA command that 
contains something improper. Enhanced status code 5.6.0 is to be 
used if no other code is more specific. 


4.2. Ensure All Domains are Fully-Qualified 


The MSA MUST ensure that all domains in the envelope are fully- 
qualified. 


If the MSA examines or alters the message text in way, except to add 
trace header fields [SMTP-MTA], it MUST ensure that all domains in 
address header fields are fully-qualified. 


Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA 
command which contains improper domain references. 


NOTE: A frequent local convention is to accept single-level domains 


(for example, ’sales’) and then to expand the reference by adding the 
remaining portion of the domain name (for example, to 
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‘sales.example.net’). Local conventions that permit single-level 
domains SHOULD reject, rather than expand, incomplete multi-level 
domains, since such expansion is particularly risky. 

5. Recommended Actions 
The MSA SHOULD do all of the following: 


5.1. Enforce Address Syntax 


An MSA SHOULD reject messages with illegal syntax in a sender or 
recipient envelope address. 


If the MSA examines or alters the message text in way, except to add 
trace header fields, it SHOULD reject messages with illegal address 
syntax in address header fields. 


Reply code 501 is to be used to reject a MATL FROM or RCPT TO command 
that contains a detectably improper address. 


When addresses are resolved after submission of the message body, 
reply code 554 with enhanced status code 5.6.2 is to be used after 
end-of-data, if the message contains invalid addresses in the header. 


5.2. Log Errors 


The MSA SHOULD log message errors, especially apparent 
misconfigurations of client software. 


Note: It can be very helpful to notify the administrator when 
problems are detected with local mail clients. This is another 
advantage of distinguishing submission from relay: system 
administrators might be interested in local configuration problems, 
but not in client problems at other sites. 


6. Optional Actions 
The MSA MAY do any of the following: 

6.1. Enforce Submission Rights 
The MSA MAY issue an error response to the MAIL FROM command if the 
address in MAIL FROM appears to have insufficient submission rights, 
or is not authorized with the authentication used (if the session has 


been authenticated). 


Reply code 550 with enhanced status code 5.7.1 is used for this 
purpose. 
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6.2. Require Authentication 


The MSA MAY issue an error response to the MAIL FROM command if the 
session has not been authenticated. 


Section 3.3 discusses authentication mechanisms. 
Reply code 530 [SMIP-AUTH] is used for this purpose. 
6.3. Enforce Permissions 
The MSA MAY issue an error response to the RCPT TO command if 
inconsistent with the permissions given to the user (if the session 


has been authenticated). 


Reply code 550 with enhanced status code 5.7.1 is used for this 
purpose. 


6.4. Check Message Data 


The MSA MAY issue an error response to the DATA command or send a 
failure result after end-of-data if the submitted message is 
syntactically invalid, or seems inconsistent with permissions given 
to the user (if known), or violates site policy in some way. 


Reply code 554 is used for syntactic problems in the data. Reply 
code 501 is used if the command itself is not syntactically valid. 
Reply code 550 with enhanced status code 5.7.1 is used to reject 
based on the submitting user. Reply code 550 with enhanced status 
code 5.7.0 is used if the message violates site policy. 


hs Interaction with SMTP Extensions 


The following table lists the current standards-track and 


Experimental SMTP extensions. Listed are the RFC, name, an 
indication as to the use of the extension on the submit port, anda 
reference: 

RFC Name Submission Reference 

2197 Pipelining SHOULD [PIPELINING] 

2034 Error Codes SHOULD [CODES-EXTENSION] 

1985 ETRN MUST NOT [ETRN] 

1893 Extended Codes SHOULD [SMTP-CODES] 

1891 DSN SHOULD [DSN] 

1870 Size MAY [SIZE] 

1846 521 MUST NOT [521REPLY] 

1845 Checkpoint MAY [Checkpoint] 


Gellens & Klensin Standards Track [Page 8] 


RFC 2476 Message Submission December 1998 


1830 Binary MAY [CHUNKING] 
1652 8-bit MIME SHOULD [8BITMIME ] 
---- Authentication —— ------ [SMTP-AUTH] 


Future SMTP extensions should explicitly specify if they are valid on 
the Submission port. 


Some SMTP extensions are especially useful for message submission: 


Extended Status Codes [SMTP-CODES], SHOULD be supported and used 
according to [CODES-EXTENSION]. This permits the MSA to notify the 
client of specific configuration or other problems in more detail 
than the response codes listed in this memo. Because some rejections 
are related to a site’s security policy, care should be used not to 
expose more detail than is needed to correct the problem. 


[PIPELINING] SHOULD be supported by the MSA. 


[SMTP-AUTH] allows the MSA to validate the authority and determine 
the identity of the submitting user. 


Any references to the DATA command in this memo also refer to any 
substitutes for DATA, such as the BDAT command used with [CHUNKING]. 


8. Message Modifications 


Sites MAY modify submissions to ensure compliance with standards and 
site policy. This section describes a number of such modifications 
that are often considered useful. 


NOTE: As a matter of guidance for local decisions to implement 
message modification, a paramount rule is to limit such actions to 
remedies for specific problems that have clear solutions. This is 
especially true with address elements. For example, indiscriminately 
appending a domain to an address or element which lacks one typically 
results in more broken addresses. An unqualified address must be 
verified to be a valid local part in the domain before the domain can 
be safely added. 


8.1. Add ’Sender’ 


The MSA MAY add or replace the ’Sender’ field, if the identity of the 
sender is known and this is not given in the ’From’ field. 


The MSA MUST ensure that any address it places in a ’Sender’ field is 
in fact a valid mail address. 
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8.2. Add ‘Date’ 


The MSA MAY add a ’Date’ field to the submitted message, if it lacks 
it, or correct the ’Date’ field if it does not conform to [MESSAGE- 
FORMAT] syntax. 


8.3. Add ’Message-ID’ 


The MSA MAY add or replace the ’Message-ID’ field, if it lacks it, or 
it is not valid syntax (as defined by [MESSAGE-FORMAT]). 


8.4. Transfer Encode 


The MSA MAY apply transfer encoding to the message according to MIME 
conventions, if needed and not harmful to the MIME type. 


8.5. Sign the Message 


The MSA MAY (digitally) sign or otherwise add authentication 
information to the message. 


8.6. Encrypt the Message 


The MSA MAY encrypt the message for transport to reflect 
organizational policies. 


NOTE: To be useful, the addition of a signature and/or encryption by 
the MSA generally implies that the connection between the MUA and MSA 
must itself be secured in some other way, e.g., by operating inside 
of a secure environment, by securing the submission connection at the 
transport layer, or by using an [SMTP-AUTH] mechanism that provides 
for session integrity. 


8.7. Resolve Aliases 
The MSA MAY resolve aliases (CNAME records) for domain names, in the 
envelope and optionally in address fields of the header, subject to 
local policy. 
NOTE: Unconditionally resolving aliases could be harmful. For 
example, if www.example.net and ftp.example.net are both aliases for 
mail.example.net, rewriting them could lose useful information. 

8.8. Header Rewriting 
The MSA MAY rewrite local parts and/or domains, in the envelope and 


optionally in address fields of the header, according to local 
policy. For example, a site may prefer to rewrite ’JRU’ as ’ 
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J.Random.User’ in order to hide logon names, and/or to rewrite ’ 
squeeky.sales.example.net’ as ‘'zyx.example.net’ to hide machine names 
and make it easier to move users. 


However, only addresses, local-parts, or domains which match specific 
local MSA configuration settings should be altered. It would be very 
dangerous for the MSA to apply data-independent rewriting rules, such 
as always deleting the first element of a domain name. So, for 
example, a rule which strips the left-most element of the domain if 
the complete domain matches '’*.foo.example.net’ would be acceptable. 


Security Considerations 


Separation of submission and relay of messages can allow a site to 
implement different policies for the two types of services, including 
requiring use of additional security mechanisms for one or both. It 
can do this in a way which is simpler, both technically and 
administratively. This increases the likelihood that policies will 
be applied correctly. 


Separation also can aid in tracking and preventing unsolicited bulk 
email. 


For example, a site could configure its MSA to require authentication 
before accepting a message, and could configure its MTA to reject all 
RCPT TOs for non-local users. This can be an important element ina 
site’s total email security policy. 


If a site fails to require any form of authorization for message 
submissions (see section 3.3 for discussion), it is allowing open use 
of its resources and name; unsolicited bulk email can be injected 
using its facilities. 
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Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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